Computer programs are sets of instructions for controlling processors in computing devices. Computer programs are typically written in one or more high level languages that are easy for a human being to understand. These source language statements are then typically compiled by a special type of program called a compiler and converted to coded instructions, which often correspond to the actual operations performed by a processor in a computer device.
Frequently the coded instructions are not identical to the native instructions for the processor, but, instead, are instructions for a particular virtual machine. A virtual machine is a process that interprets coded instructions and executes them. The virtual machine itself is an executable sequence of instructions in the native language of the processor. Virtual machines are sometimes called interpreters. As used herein, the term “machines” includes virtual machines interpreting virtual machine instructions, operating systems interpreting operating system instructions, and processors executing native instructions.
In general, coded instructions from one or more modules can be linked to form an executable program. Modules can consist of source language statements, coded instructions for a particular virtual machine, runtime executables, or some combination of these, with or without associated data. Modules in a high-level source language may be compiled by a run time compiler to produce corresponding modules in coded instructions.
It is becoming more common to create programs that include heterogeneous modules. For example, a program may include a machine-executable module, a module executable by a first type of virtual machine, and a module executable by a second type of virtual machine. During execution of the program, a routine in the machine-executable module may call a routine in the module running in a first type of virtual machine, and that routine may call another routine in the module running in a second type of virtual machine.
In addition, it is common for programs executing on different processors to interact with each other. For example, an application program, such as a network management program, runs as a first process on one processor on one device on a network. While running, the first process may make a request of a device management server program (the “server”), a second process executing separately on a second device on the network, to provide management information about the second device. In turn, the second process may launch a local configuration program as a third process executing separately on the second device or invoke a user authentication program executing on a separate third device. The local configuration program determines properties of the local device by either getting the current status of the local device or changing the status or both. In many situations, the interacting programs will be written by different programmers in different organizations for different types of virtual machines on the different processors. For example, one will be a Java program, while the other is a C language program.
It is also typical for each process that runs to log certain events in a log file written specifically for that process. Logged events might include, for example, reaching certain milestones in the processing of data, encountering particular user actions, invoking separate processes, receiving results from separate processes, invocations by separate processes, returning results to separate processes, and encountering an error or interruption in processing. The log files are often important in determining what a process spawned from a module actually does when a particular user under particular circumstances executes the instructions in the module. Sometimes what a process does contrasts with what it was designed to do because of equipment failures, external problems, or because some circumstances were unanticipated by the programmers of the module. The log files help developers of each module determine the actual performance of processes spawned from the module. Typically, the log files are specific to a module; the events are identified and event properties are represented in ways specifically designed by the developers of the module.
A problem arises when it becomes useful to track an event across log files written by interacting processes spawned from separately developed modules, often executing on different processors. For example, an error encountered by the third process causes an error event to be entered in the log file for the third process along with data about the error of concern to developers of the third module, the local configuration program or the authentication agent program. The error is identified in the third log file by some error code, X, determined by the developers of the third module. The third process may then enter other information into the log file.
As a result of the error, the third process returns control to the calling process, the second process, with some indication of error. The error indication returned by the third process to the second process causes an error event to be entered in the log file for the second process along with data about the error of concern to developers of the second module, the device management server. The error is identified in the second log file by some error code, Y, determined by the developers of the device management server and may be unrelated to X, the code that identifies the error in the third log file. The second process may then enter other information into the second log file.
As a result of the error, the second process returns control to the calling process, the first process, with some indication of error. The error indication returned by the second process to the first process causes an error event to be entered in the log file for the first process along with data about the error of concern to developers of the first module, the network management program. The error is identified in the first log file by some error code, Z, determined by the developers of the network management program and may be unrelated to the way the error is identified in the second log file.
A user of the first process will find it difficult to retrieve information about the error event stored in the log file for the third process. The error identification, X, used in the third log file is unknown to the user of the first process.
One approach that could be pursued is to require each current process to pass the error identification in the current process, determined by the developers of the module for the current process, to the calling process that called the current process. In addition, the current process stores the error code returned from a called process in the log file along with the error identification. For example, the second process stores the value X along with the value Y in the second log file; and passes the value Y to the first process. Then, the first process stores the value Y along with the value Z in the first log file. A user of the first process can retrieve information about the error event stored in the third log file by tracking backwards through the second log file. For example, the user finds in the first log file that the error Z is associated with the error Y; then searches the second log file to find that the error Y is associated with the error X; then searches the third log file to find the error X and the information about the error X.
One problem with this approach is that a user must track the error through all the log files of the intervening processes. Another problem with this approach is that the error codes may not be unique. For example, the error code X might appear several times in the third log file, every time the third process encounters the same problem; or, the error code Y might appear several times in the second log file; or both error codes might appear several times in their respective log files. There might not be sufficient information to determine which error identification is associated with the event of interest to the user.
Another approach that could be pursued is to require each current process to identify an error in the current process by the error identification returned from a called process, to use the same error identification in the log file, and to pass the same error identification to the calling process. For example, the second process stores the value X in the second log file, and passes the value X to the first process. Then, the first process stores the value X in the first log file. A user of the first process can retrieve information about the error event stored in the third log file by going directly to the third log file. For example, the user finds in the first log file that the error identification is X; then searches the third log file to find the error X and the information about the error X. The user does not have to search the log files of all the intervening processes.
One problem that remains with this approach is that the error codes may not be unique. For example, the error code X might appear several times in the third log file, every time the third process encounters the same problem. There might not be sufficient information in the third log file to determine which error identification is associated with the event of interest to the user.
Based on the foregoing, there is a clear need for a tracking one event through multiple files, each file written specifically for a process that executes instructions in one module.
The past approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not admitted to be prior art to the claims in this application merely by inclusion in this section.